A Web service is a software application can that be accessed remotely (namely over the Web), and using an XML-based language. A Web Service can be identified by a URI (universal resource indicator) in the same way as a conventional web site, or more typically will be accessed from some registry of web services.
A Web service program provides XML documents which are typically formatted in accordance with the rules of the SOAP specification. SOAP is essentially a message format which is not bound to any hardware or software architecture. The underlying transport mechanism is typically HTTP, although other transport protocols such as JMS or SMTP may be used. The Web Services Invocation Framework (http://ws.apache.org/wsif/) provides software components to aid in the use of different protocols and/or web service implementations.
The aim of the protocols established relating to Web services is to provide interoperability between different computer systems, running different languages on different operating systems. This facilitates the implementation of distributed computer systems. This is in a large part due to the ubiquity of its use of XML (Extensible Markup Language).
The established Web-based communications protocols are designed to enable text and image documents to be transmitted (namely Web pages), and essentially provide simple object access protocols.
In order to enable software applications to be described using a specification that is again independent of programming language and operating system, the Web Services Description Language (WSDL) has been devised. The specifications are available from the W3C web site (http://www.w3c.org/2002/ws/). This language is again based on XML, and provides a platform for the information needed to connect to a remote Web service. A WSDL document can be treated as two related but logically distinct sections: the abstract description which describes the functional behaviour of the web service; and the binding which describes how messages should be serialized onto some underlying protocol to send to the Web Service.
The binding description provides elements enabling the binding of a client to the Web service physically, namely the path and port connections. In the following description, the binding as currently used is referred to as “concrete” because it defines exactly all the connection information required for a client to immediately interact with a web service.
The abstract description provides elements describing the capabilities of the Web service, namely describing the Web service functionality. This essentially describes the input and output message formats that each web service operation accepts and generates respectively.
The binding essentially describes how the methods belonging to the abstract description can be invoked using common protocols like HTTP. Invocation of a method involves the submission of a message and usually a response message is received. When the response is received by a service directly in response to a request from a client, such an interaction is referred to as synchronous. When the response is not returned directly, but is delivered by the service using an agreed operation provided by the client, the interaction is regarded as being asynchronous. Usually, the asynchronous callback occurs some while after the original request. The ‘agreed’ operation is usually referred to as a callback method or function.
Another common interaction pattern in computer science is the listener pattern. This uses a callback method as in asynchronous interaction. However, instead of sending a request to the service, the client simply indicates its interest in receiving events produced by the service. The callback methods/operation is used by the service to send these events to the client. The events in this case are generated independently of the client rather than in response to a client request.
One limitation to Web services derives from the use of Web-based communications protocols. For example, the transport layer is typically HTTP. HTTP was designed to allow one server to handle hundreds of requests quickly, by not maintaining a long-term connection between the clients and server. A server will typically not maintain any state information to keep track from one user request to the next, so that the handling of multiple requests can be handled efficiently. Furthermore, HTTP inherently uses a synchronous form of interaction.
This transactional nature of Web based protocols such as HTTP has some incompatibility with asynchronous messaging.
Asynchronous messaging is a key element to the development of distributed computer systems. Asynchronous messaging enables the decoupling of a client from a server, so that a client program can request a service from the server, and continue with local processing tasks while the server response is awaited. Asynchronous messaging does not require any synchronisation of the data exchange and no permanent connection between client and server needs to be maintained.
Asynchronous callbacks involve calling a remote function provided by a Web service which is in response to an event not initiated by the Web service client. Simplistically, a callback is a method or function provided by a software component that allows another component to notify that an activity, requested some time ago, has completed. When a client invokes a method on a remote service the response message needs to be delivered to some callback address implemented by the client that originally invoked the method. Support for callback methods is necessary to support asynchronous messaging in general.
Asynchronous callbacks may be provided to give update information of many different types, for example in connection with stock or other prices, in connection with the status of a processing operation at the Web service etc.
The WSDL structure implies a support for asynchronous callbacks, but in practice it is not possible to support asynchronous callbacks using WSDL. In particular, WSDL does not provide a facility for defining the binding (part of the concrete description of the WSDL document) ahead of runtime. This prevents the implementation of asynchronous callbacks, because the callback address is unknown until runtime. In addition, there can be many potential clients and therefore many potential callback addresses.
New Web Service related specifications are continually being introduced, typically created to provide support for additional functionality. However, these additional specifications introduce further complexity and may potentially hinder the acceptance of Web services technology by introducing interoperability difficulties. They also limit the choice of protocol mechanism, most typically supporting only SOAP (Simple Object Access Protocol). Several of these specifications are under development within the World Wide Web Consortium (www.w3c.org) and OASIS (Organization for the Advancement of Structured Information Standards at http://www.oasis-open.org/home/index.php).